Similar to the --ext-code changes in #171, --tla-code is meant to be able to take arbitrary Jsonnet code just like --ext-code can, and before this PR we limited it to only JSON

I refactored out the common Interpreter#parseVar logic so it can be shared between both, and added new tests to exercise the new behavior.

The override def evalDefault for the Val.Func used for top-level functions needed to be fixed; there was always a logical issue evaluating the --tla-code expression using the main file's ValScope, but it didn't matter since previously we only allowed JSON so there weren't any identifiers to look up using it. Now that there are, the correct thing to do is to evaluate the --tla-code expression using ValScope.empty, since it is meant to be a standalone expression without any existing local bindings in its lexical scope

Notably, --tla-code expressions cannot reference each other the way --ext-code expressions can, so there is no equivalent to the stdExtVarRecursive test case. They can still call std functions, so the std test case remains